Oracle TimesTen Cache Connect to Oracle開発者および管理者ガイド

パススルー・レベルの設定

アプリケーションで、TimesTenの単一の接続を介して、TimesTenまたはOracleのいずれかにSQL文を送信できます。

SQLがTimesTenまたはOracleのいずれに送られるかは、SQL文の構成およびPassThrough接続属性の設定によって決まります。PassThrough属性を設定して、TimesTenでローカル処理されるSQL文のタイプおよびOracleにリダイレクトされるSQL文のタイプを定義できます。

たとえば、PassThrough=0（デフォルト）を設定すると、すべてのSQLがTimesTenで実行されます。また、PassThrough=3を設定すると、すべてのSQLがOracleに渡されて実行されます。

図3.10に示すように、PassThrough=1を設定すると、TimesTenに存在しない表またはTimesTenで構文エラーを生成する表に対するSQLをパススルーできます。たとえば、キャッシュされた表（表A）に対するUPDATEはTimesTenキャッシュで処理されますが、TimesTenで検出されない表（表G）に対するUPDATEはOracleにパススルーされます。同様に、ttCacheStart、ttCkptなどのTimesTen固有のプロシージャはTimesTenで処理されますが、TimesTenでサポートされていないプロシージャはOracleにパススルーされます。

図3.10 TimesTen単一接続機能

PassThrough=1と設定すると、DDL文はOracleにパススルーされません。TimesTenに存在しないプロシージャはOracleにパススルーされます。キャッシュ・グループ表のDML文に誤った構文が含まれている場合、そのDML文はOracleに送信されません。ただし、誤った構文を含むすべてのSELECT文は、Oracleに送信されます。

キャッシュ・グループを作成する場合は、いくつかのキャッシュ・グループ・タイプから選択できます。これらのキャッシュ・グループ・タイプの1つとして、キャッシュ・グループでのDML文による更新を禁止するREADONLYキャッシュ・グループがあります。READONLYキャッシュ・グループを使用する場合は、PassThrough=2を設定して、キャッシュ・グループ内の表に対するすべてのDML文をOracleに送ることができます。それ以外の場合、この設定はPassThrough=1と同じであるため、すべてのDDL文、DML以外の構文的に互換性のある文およびプロシージャは、TimesTenに送られます。同じパススルー動作が、USERMANAGEDキャッシュ・グループのREADONLY表に適用されます。図3.10のキャッシュ・グループの例について考えてみます。READONLY属性を表Aに設定し、PassThrough=2を設定すると、表Aに対するUPDATEはOracleにパススルーされます。

パススルー機能は、AWTおよびSWTキャッシュ・グループ内の表に対するDML処理では使用しないことをお薦めします。AWTキャッシュ・グループでの更新は、定義上はキャッシュと非同期ですが、パススルーによって同期するようにレンダリングされ、それによって意図しない結果になる場合があります。SWTキャッシュ・グループでの更新は、パススルー機能が実装されている場合、自己デッドロックが発生する可能性があります。

SQL文がTimesTenで実行されるか、Oracleにパススルーされるかの決定に対するPassThrough属性設定の影響およびその状況の詳細は、『Oracle TimesTen In-Memory Database APIリファレンス・ガイド』のPassThroughに関する説明を参照してください。

パススルーとパラメータのバインド

アプリケーションがPASSTHROUGH文に対して正しいSQLデータ型を提供していることを確認してください。ODBCドライバはC型およびSQL型を変換し、変換されたデータおよびSQL型コードをTimesTenに提示します。TimesTenはこの情報をOracleに渡します。

TimesTenは、TimesTen自体で実行される文のパラメータとは異なる方法で、PASSTHROUGH文のパラメータを処理します。TimesTen問合せオプティマイザはデータ型をTimesTen文のパラメータに割り当てます。アプリケーションは、SQLDescribeParam ODBC関数を使用して、これらのデータ型割当てを取得できます。これに対して、PASSTHROUGH文のパラメータにはデータ型が割り当てられません。TimesTenはPASSTHROUGH文のパラメータのデータ型をVARCHAR2(4000)としてレポートします。このデータ型は単なるプレースホルダです。TimesTenがパラメータ値をVARCHAR2データとして受信することを予測しているわけではなく、SQLBindParameter ODBC関数をコールするときに、アプリケーションはPASSTHROUGH文のパラメータのデータ型についてTimesTenに通知する必要があります。SQLBindParameterのfSqlType引数はパラメータのSQLデータ型を指定します。cbColDefおよびibScale引数はその精度およびスケールを指定します（適用可能な場合）。

たとえば、SQLデータ型INTEGERのパラメータをNUMBER(3)パラメータにバインドするには、次の引数を指定してSQLBindParameter ODBC関数をコールします。

fCType=SQL_C_SLONG

fSqlType=SQL_DECIMAL

cbColDef=3

ibScale=0

また、次の引数を使用できます。

fCType=SQL_C_SLONG

fSqlType=SQL_INTEGER

cbColDef=0

ibScale=0

SQL_INTEGERについてcbColDefおよびibScaleは無視されます。

パススルー・レベルの変更

DSNのPassThrough設定は、ttIsqlセッションのpassthroughコマンドで上書きできます。ttOptSetFlagプロシージャをコールし、optflagパラメータとしてpassthroughを指定し、optvalパラメータとして新しいパススルー設定を指定することによって、プログラムでも特定のトランザクションのパススルー設定を再設定できます。新しいパススルー設定はすぐに有効になります。トランザクションの最後に、パススルーはPassThrough属性で指定されている元の値にリセットされます。

注意:

PassThroughは、文の準備時に設定されるPassThroughレベルは文の実行時に使用されるレベルであるという点で、他のオプティマイザ・フラグと同様に動作します。文を準備してから文を実行するまでの間にPassThroughレベルを変更すると、現行のPassThroughレベルは無視されます。